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Introduction 


Microservices cannot be simply ‘wired up’ with some basic technical 
knowledge about what constitutes a Microservice Architecture. There is 
more to a Microservice Architecture than developing isolated and unique 
services with a blueprint like set of architectural artifacts. Successfully 
understanding microservices requires a paradigm shift no less radical than 
moving from a procedural to an object oriented programming language. 


This book will take you on an expedition to a yet to be fully explored 
‘planet’ with a divergent philosophical underpinning that is completely alien 
to some technologists. Our voyage of discovery will be traveling through a 
landscape that is unrecognizable. If it were not for the historical map that 
explains the origins of this empowering technical perspective most would be 
disoriented at the outset of the voyage. 


Traveling to this new land of freedom requires that explorers not take any 
neat and tidy preconceptions with them - come along without any baggage. 
This book will challenge how you view technology to the core of your 
being. When you have finished this journey all that you believe and cherish 
from a technical standpoint will be cast aside. Let’s begin our odyssey... 


Early Years 


Falling into the profession of what was then called programming my skills 
and interests were tickled at a very early age by an after school class in 
FORTRAN. Miami Killian Senior High back in the mid-1970s was situated 
within an upper-middle class neighborhood in what was termed South Dade 
- geographically the Dade county metropolis dominated by Miami, Florida. 


You have to understand that way back when dinosaurs roamed free across 
unfenced villages programming was considered a far-out fringe occupation 
that engaged super-brainy types who worked for IBM and a few other very 
large computer companies. Sometimes the U.S. military through its network 
of military contractors like Lockheed would also grab those who had the 
requisite knowledge in technology. So for a high-school to setup a large 
room with many large green bar printer terminals linked to the school 
district’s IBM mainframe just to teach programming to a bunch of math 
wizards was quite the leap off the deep end. 


Mostly what I remember from those classes is the math on the blackboard, 
lots of notes, and clouds of chalk dust as the teacher kept plowing through 
the concepts of the language. Those of us fortunate enough to pass 
intellectual muster to be selected for the class felt giddy - like we were 
astronauts for a moon mission. We faithfully typed our simple formulas into 
the clumsy green large typewriter contraptions with keys that were not so 
different from an electronic typewriter - an IBM Selectric comes to mind. 


Alright, for those of you who are struggling to picture this stone-age setting 
suffice to say all of us class dwellers were a super exalted group of 
youngsters. This was the turning point in my life where I realized that my 
path all that mattered in my singular existence was centered on those circuit 
filled boxes buzzing with formulas that we wizards entered in those large 
green paperweights. While studying, my thoughts would float to my brilliant 
future in this new and exciting career that was free from excessive 
processes, full of experimentation, and an endless procession of trials and 
errors sometimes leading to eye popping results. 
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Liftoff, most of us in the class had made it to the moon, or what we felt was 
something just as exhilarating. An insightful school board had done their job 
turning on a few bright kids to the possibilities of a computer profession. 
Building Heathkits became a passion with me, along with becoming 
proficient in a few programming languages. Much later after working a few 
odd jobs because my parents hadn’t saved any money to send me away to 
university my interests shifted to a procedural language called BASIC. 


Using a Commodore 64 and later a Commodore 128 to program on with the 
BASIC language I was able to create a word processing program that I used 
to type up my assignments when attending Miami-Dade Community 
College back in the early 1980’s. After completing my AA degree at the 
community college I took a few courses at Florida International University. 


When after a bad marriage had me moving from Florida to the Cincinnati, 
Ohio area and working at what was then the Cincinnati Credit Union 
(CCCU) from 1987 to 1995 as an Accounting Clerk my passion to learn was 
once again ignited but still constrained to business degree related courses 
because these were the only programs that firms would consider for tuition 
reimbursement. Nowadays, these employer funded tuition reimbursement 
programs are like rare albino rhinos. 


Taking course work towards an Accounting degree at University of 
Cincinnati from 1988 - 1990 but not enjoying the very large setting of this 
university I finally settled at the newer and significantly smaller Northern 
Kentucky University in 1991. Still dreaming of using my programming 
skills only explored at home on my computers but not having the money to 
pursue my dream profession and scared to go into hock with student loans I 
drifted along in my business coursework. 


Majoring in Accounting bored me to tears so I shifted my major to 
Economics because CCCU would pay for this degree even though it was not 
a pure business related major. Later in my tenure with CCCU my 
programming knowledge starting coming to the forefront with my learning 
Lotus 123. Never dropping BASIC, but also picking up C and using more 
powerful personal computers my programming knowledge expanded. 


It is hard to convey how those of us engaged in the early days of modern 
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technology felt. We were the originators of something grand and we knew 
it! Every day was an adventure into the unknown; our joyous treks into the 
unexplored realms of our intellectual passion were unbounded. 


The thrill of learning something extraordinary and the constant discovery 
engaged our creative juices without excessive rules, processes, or 
roadblocks. Our exploring minds were wide open, a boundless expanse from 
horizon to horizon beckoned to us first bold explorers. Keep in mind that 
during these early days Bill Gates and Microsoft were only known by a very 
few folks at IBM. This was the beginning of something - we just did not yet 
fathom at this early stage what it would become. 


After graduating from Northern Kentucky University with a BS in 
Economics and an area of concentration in accounting in May of 1995 both 
me and my new wife Diana moved to Indianapolis, Indiana with our small 
boy. Determined to start doing some programming of some sort I started 
work with Day Dream Publishing a calendar publisher in the late 1990’s as a 
Production Coordinator. 


This was a great position to get my feet wet in corporate programming that 
was not overly complex but just right for a newbie. Writing Microsoft 
Visual Basic for Applications (VBA) Excel and Word macros, and FoxPro 
desktop database applications my days at the office were finally joy filled. 
Even more exciting, was my first interactions with an early enterprise 
database called Informix using SQL that was taught at the office. 


With not much process, or other details other than a single page set of 
requirements these rudimentary applications required and relied mostly upon 
the existing MS OS and the MS Office program frameworks. FoxPro had 
just been acquired by Microsoft to either supplant its Access desktop 
database or supplement it - later when the FoxPro product was dropped from 
Microsoft’s software offerings it seemed at the time that they had purchased 
FoxPro to gain technology for their MS SQL Server enterprise database - 
but do not quote me on this. 


Transitioning from my early beginnings writing macros for MS Office 
products my skills were directed at programming MS Visual Basic (VB) 
applications for yet another publisher and then for American United Life 


12 


(AUL) a mutual insurance company that became One America. This is 
where my title officially became Software Programmer. 


My first experience with a real, though obviously flawed programming 
process was at AUL. AUL used the Waterfall process, each programmer 
both mainframe and standalone application variants worked closely with a 
Business Analyst. Due to the small scope and size of these early applications 
each programmer had their own personal Business Analyst who ultimately 
became a close friend. These experts seemed to always have the answer to 
our questions - intimately knowing their customers and their needs and the 
business from top to bottom. 


My job in the Group Life division at AUL was to create MS Visual Basic 
standalone applications used by our remote staff offices. This was a dream 
come true. Not only was I doing what had been my life’s love but I finally 
had the recognition and respect that came with creating useful programs, and 
also the title. 


Not much was asked of us programmers in the late 1990’s except to produce 
programs that worked and were easy to use. Our Business Analyst would 
meet with us to discuss what their expectations for the system were and 
present us with moving target requirements that changed regularly through 
the Waterfall development phase. Therefore out of necessity, the 
applications that we designed employed the concepts of what would be 
known many years later as Evolutionary Architecture. There were not many 
architects to go around so our applications had to be very malleable to 
accommodate all the requirement changes that our Business Analyst kept 
throwing our way. We learned early on about building in adaptability into 
our applications. 


We were a tight group of professionals at AUL because we were the chosen 
few lucky enough to be employed with the premier Indianapolis employer in 
an exciting profession in the heart of early exploration and innovation. Just 
about every day we would go to lunch leaving our office building adjacent 
to the AUL skyscraper. Thinking back on those days it is hard to believe 
how antisocial technologists currently are with their heads down total focus 
on their computer screens. This just was not the case back in the early years 
when anything seemed possible and specialization within technology had 
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not yet taken hold. 


After my stint with AUL my goals were realigned from nights learning what 
was then the relatively new Java language. This was like a breath of fresh 
air, an elegant object oriented language that was not some contrived mess 
like MS Visual Basic but a full featured real language like C++ but without 
the memory loss issues, or so we believed at the time. 


Walker Information was experimenting with Java standalones, and being 
another premier Indianapolis area employer I leaped at the opportunity to 
program in this exciting language. My position title was upgrade to Software 
Programmer II and entailed designing and developing what was probably 
the first BPM strategic management application - at least it was billed as 
such by management. This was really exciting stuff programming in this 
elegant full-featured language and working with XML, XSLT, writing my 
own DTDs, and working with an Oracle database. The skills that had taken 
me many years to hone to a fine sharp edge were finally being utilized. 


My first exposure to Agile was in 2001. Aeroflex Altair Cybernetics in 
Bowie, Maryland was experimenting with Pair Programming in what was 
then a very progressive organizational structure led by an enlightened 
former Navy Aviator. This was an organization that valued the contributions 
of each and every member of its various teams. Aeroflex understood that a 
purely hierarchical organization structure superimposed upon what was their 
primary business, creating software products that maintained the orbits for 
NASA and Northrop Grumman satellites would negatively impact the 
creativity and productivity of their engineers. 


Aeroflex could not yet foresee the pure cross-discipline Agile teams that 
infused operations, development, and other professionals. DevOps, the 
automation of CD, CI, and Continuous Deployments empowered by an 
organizational structure that valued cooperation and collaboration had not 
yet been envisioned. Insightful enough to engage the entire technology staff 
in daily meetings that were almost Scrum like in their collaborative anti-silo 
results and freeing the technology team from hierarchical control 
impediments Aeroflex fostered an environment of continuous discovery. We 
truly were energized and working together to solve all the technical 
challenges and blaze new paths of exploration leading to many technology 
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breakthroughs! 

Unfortunately, having only a few companies understand that overt control 
structures like a hierarchical top-heavy dictatorial autocracy was detrimental 
to the creative process would not significantly change engrained business 
principles. 


In the early 2000s, coding in the Java language required the compilation of 
JAR files containing all the code of the application. Dependencies used by 
the application were placed in a “lib” folder under the root of the 
application. Whether a Java standalone with a SWING UI or a web 
application with Java Server Pages (JSP) and Servlet controllers the primary 
container was the compressed and executable JAR file. The winds of 
corporatism were blowing hard and were about to wipe clean what had been 
a relatively productive and pleasant development process and environment. 


Enter the monolith in the form of the application server. JBoss was one of 
the first, meeting the Sun Microsystems specifications for what was termed 
a J2EE application server this open source framework started out fairly 
basic, it was not yet the Red Hat blob it was to be transformed into many 
years later. IBM with their WebSphere application server and integrated 
technologies from their acquisition of Rational Software was another leader 
in what was to become the framework wars. Oracle would also soon enter 
this lucrative market with their WebLogic server. Sun Microsystems the 
creator of the Java language had their NetBeans. All these J2EE compliant 
platforms had their own integrated development environments, web servers, 
and all the associated tools and processes to build and deploy the resulting 
Java EE applications. 


With the new monolith design pattern enforced by application servers the 
businesses could impose order in technology, eliminate the disorderly, 
chaotic, and unruly dreamers from their kingdoms. Promising regularization 
and perfection, the application server companies like Microsoft with .NET, 
IBM, Oracle, and others that complied with the Java EE specification could 
guarantee that divergent nerds would be reined in, they were finally under 
the heel of the corporate controllers. Java EE WAR files ported to the 
application servers and the functionally focused UI, middleware, and back- 
end layers were all 'nicely' integrated into a cross-context mess of 
interconnections making it impossible for any dreamy creative type to stray 
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from a now production focused churn. Production was all that mattered to 
the corporate controllers who were not equipped to understand what they 
considered flaky ‘black tee shirt’ wearing freaks. 


These comprehensive frameworks made their debut sometime around 2002. 
The application servers (monoliths) guaranteed that developers would have 
more time to write good code. They also enforced enough constraints to 
force developers from taking off on innovative adventures that negatively 
impacted production and the all-important bottom-line. Assimilating these 
unruly divergents into the corporate culture would now be much easier. 
They had to conform or get out. 


Architects could now architect complete systems, operations deal 
exclusively with the infrastructure, and this enforced compartmentalization 
would ‘free’ developers from worrying about all the messy details like the 
network, deployment, scaling, security, and especially time consuming 
creative diversions from their primary production tasks. This was nirvana to 
many a tightly wound dictatorial corporation. Little did we know at the time 
that going down this path would be a major mistake, leading to the further 
bifurcation, compartmentalization, specialization, and siloing of many 
previously simple processes, procedures, and technical professionals - the 
stifling of creative talent now shackled to the monolith. 


Central to the design pattern of a monolith is that it keeps the organizational 
culture in a state of stasis - change in an autocracy is never welcomed. By 
handling all the plumbing issues like scaling, leaving the developer to 
concentrate only on the coding, the polyglot, creative, and diversely talented 
technical engineer could be easily replaced by interchangeable Coders. 


Limited skill was now the hallmark of the new stamped out programmer. 
Droids who were even minimally competent at dealing with their limited 
coding related issues were hired in droves. There was now a trail of poorly 
written code, without adequate comments, and mangled up so badly that it 
typically took months just to understand the mess. Where programming was 
an art form practiced by passionate designers and inspired by love of the 
work there was now wads of production crud coded up by hacks. Tangled 
control flows that had to be unraveled whenever the monsters blew up were 
found in just about every application. 
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Slicing responsibility for the system into many tiny pieces each portioned 
out to particular technology ‘experts’ ensured no single individual would 
command sufficient comprehensive knowledge to ask for a raise, make a 
fuss, or disregard the uninformed demands from up high. The company bean 
counters were satisfied with the partitioning of responsibility, the 
Taylorization of tasks to their simplest functions. Architecture, Operations, 
Development, and Testing would now have well-defined lockstep 
responsibilities not to overlap within the centrally controlled organization. 
The paradigm that enforces the Waterfall process of long cycles - sometimes 
over many months, all structured, procedure laden, detailed, and controlled 
from up high could now be protected from all those overly creative, 
‘unusual’, and open-thought deviant technologists. 


Marketing campaigns for these gigantic application server beasts had 
unlimited budgets because the firms touting the astounding benefits of these 
monolith design pattern enforcers were setting themselves up to make a 
fortune moving the technology folks into silos that the similarly monolith 
top-heavy firms could comprehend. Order was finally established, especially 
in the view of many firms that had tried to make a go of the early Agile 
processes but felt uncomfortable about all the collaboration, cooperation, 
and teamwork within what was essentially a confrontational Capitalist firm. 
Most businesses were now satisfied that the chaotic and messy development 
process was finally, once-and-for-all, Taylorized, ordered, and 
compartmentalized. 


The outcome of all this order was the sought after stifling of creatively, 
collaboration, cooperation, and dynamism that were at the heart of early 
development shops. 


Contrary to popular myth, developer polyglots in those early years were not 
introverts - on the contrary we were very engaged in blazing new paths in 
uncharted technical territory. We were always going out for lunch, having 
impromptu meetings (way before Scrum), eating together in the break room, 
and visiting each other’s desks. Even those who were really good at 
maintaining the infrastructure, all the future operations sysops crowd were 
like the rest of us - cut from the same mold - show and tell inventors. 
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Everyone was on a journey of discovery, an exciting adventure, paths not 
yet traveled were opening up, we daily had something new to relay - it was a 
giddy time of discovery, unbridled creativity, the experience of uncovering a 
revolutionary new discovery or idea - all of us could not wait to pass our 
enthusiasm and creative insights on to our fellow engineers. Little did we 
know that all this unfocused inventiveness was slowly being locked down to 
the monolith creepy crawlers - those replicas of big ‘well ordered’ 
lumbering corporations. Regressive change putrefied the stall air of the 
windowless cubicle farms. 


What I will term the ‘Lock Down’ occurred sometime around 2004. 
Established firms decided that all this communication between their unusual 
technical employees had to be stopped once and for all - they must fall in 
line like all the rest of the mechanoids. Everything about these technical 
folks was adverse and destructive to a corporate firm that prided itself on 
firm control over every aspect of the organization. These engineers, 
developers, coders, and assorted flighty brainy types had to conform; they 
were just too divergent a 'species' for any respectable, hierarchically 
organized, highly planned, and shortsighted organization to stomach. 


Firms like IBM spent heavily on the marketing of WebSphere and the 
Rational suite of products that firms happily paid fortunes for because these 
businesses were more than ready to silo their unruly, creative, and unusual 
cloud thinkers. Control down at the code level, detailed architectures, even 
UML object models of individual classes, every minutia of the design in a 
certified Waterfall process that had extensive and regressive testing tools 
and 'teams' to do the testing before the monolith hit production were 
enforced within The Framework. Businesses felt they had finally reached 
heaven, the Promised Land; they could once again sleep at nights knowing 
that these weird technology folks were finally under the yoke of business 
dominance. The chains were securely shackled to the former “black tee 
shirt” wearing weirdos - they would never be able to break free. 


When it was finally realized that the organization structure of these mega- 
businesses was negatively impacting the safety, maintenance, ability to 
scale, and many other factors of bringing to production the unwieldy 
monolith framework constrained systems it was too late. Firms realized that 
they had already spent far too much money, created systems that were 
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bloated, unwieldy, and had no chance of scaling to an Internet that was no 
longer having hundreds or thousands using these monoliths but millions. 
The next age - the revision back to the basics of the dawn of computer 
technology was about to once again empower those who could be the 
creative force inspiring positive change - the polyglot software engineers - 
those few capable of envisioning and directly focusing innovation within a 
constantly changing dynamic - diverse teams of multifaceted intellects 
focusing their innovative energy on a global scale. 
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Welcome Back the Change-Agents 


Autocratic organizational structures with their integrated chains of command 
mimicked in the software processes, tools, and tightly coupled outcomes of 
synchronized production are diametrically contrary to the dynamic and 
ubiquitous freedom of expression of the billions of individuals now using 
the Internet. Our organizational structures are therefore not in sync with a 
more enlightened freedom and interflow of innovation and expression 
streaming across the Internet. 


In their attempt to stifle intellectual expression, many firms locked down 
their developers in even more stringent over the top processes now fully 
integrated into the tools they were using to design and code applications. 
There just was no letup by the process hounds fresh on the trail to more 
fame and fortune. No one even thought to ask the technologists doing the 
work how this would impact their productivity, innovativeness, and 
especially the quality of the systems they were supposed to produce like so 
many widgets popping off a production line. 


Slow and cumbersome development processes like the Rational Unified 
Process (RUP) along with the lingering Waterfall Process were misaligned 
to an Internet community that was burgeoning with ideas, social networked 
associations, and scaling up from thousands to billions of users all 
demanding swift response times. 
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Hierarchical Organization structure 


Freedom was something to be experienced by everyone on the Internet; it 
was a Culture separate and distinct from anything yet created by myopically 
focused barrier enthusiasts. Old world paradigms demanding that human 
beings on a single planet be segregated behind imaginary borders were now 
found to be provincial, an anachronism no longer relevant to the connected 
world. 


Governments geared towards the betterment of the rich and powerful at the 
expense of the general population were now contrasted to the real freedom 
of expression of the millions of communities sprouting up across a 
borderless Internet. Many millions joined the seemingly limitless 
discussions, debates, discourse, and chaotic communication anarchy across 
the most extensive network ever envisioned by humankind. 
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Aside from the threat governments faced from the Internet because billions 
were now expressing themselves unencumbered by the endless barriers 
erected by those wanting a divided humanity to better maintain control was 
the sheer volume of connections, a scale never imagined possible. A scale 
that amounted to a few brave souls like myself using FTP and hitting the 
first static websites back in the early 1990’s was now exploding to millions 
pounding a single website. 


What was possible in the early giddy years of the Internet with a ‘powerful’ 
server box connected to a T1 line was now considered a bygone absurdity 
on a TCP/IP network that had not a few tinkers, but the world now 
participating in - demanding easy access to without restrictions. Firms faced 
with increased scaling needs first just bought bigger and bigger boxes to 
handle the traffic, but even this simple solution was dwarfed by what was to 
come in a few short years. 


Around the turn of the century it seems everyone was on the Internet using 
more friendly browsers, buying products like books from Amazon, and just 
starting to reach out to those using email that in the past they might have 
sent a letter to with a snail mail carrier. New online merchants like Amazon 
were vertically scaling hardware trying to keep up with the insane traffic. 
This hardware arms race started to fail much later in the early 2000’s. Firms 
like Amazon at the forefront of the online merchandise craze started adding 
virtual machines (VMs) in an attempt to keep their saturated systems from 
being overloaded by billions of folks who just had to get on the Internet. 
After all, it was so damn convenient! 


How did the locked-down software processes fair in what was becoming a 
much more turbulent world? Waterfall, IBM’s Rational Unified Process 
(RUP), and pseudo Agile integration cycle focused software processes were 
still too long - months instead of days or hours before reaching production 
deployment. Production artifacts like huge WAR files created by highly 
integrated lockstep development with full-regression testing, and demanding 
long integration top-heavy checks-and-balances were not well-suited for a 
constantly changing massively scaled Internet. 


There was no agility in processes, tools, and production marching armies 
within huge corporations. Even smaller firms geared to serve a stasis 
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engendered autocracy could not comprehend or cope with the numbers 
hitting their websites and the demands of these newly freed human beings. 
With so many opportunities to connect with others whom they could only 
dream about ever meeting in exotic countries or places that in the past 
required long plane trips, people could not help but take advantage of the 
effortless connectivity. 


Even the capitalist economic model that was previously in danger of 
becoming lethargic in industries that had lurched along without stimulation 
from inside or outside their comfortable domains was finally being 
invigorated and jolted by the infusion of new ideas being generated by all 
the electronic connections. Competition between businesses, a great driver 
of perpetual change, at least outside of industry dominated oligarchies, was 
once again occurring, especially within the technology sector. Change was 
too fast for the giant firms lulled into complacency by formerly quiet option 
limited customers. The demands of ever larger legions of user customers 
could not be ignored. Large organizations threatened by startups had to 
adapt or become historical footnotes. 


Not wanting to cede control over to their employees, the larger firms looked 
frantically for processes and methods of operation that still allowed them to 
remain in complete control over the majority of their workers. These new 
processes would be mostly focused on empowering the technology staff that 
was the central driver of the innovation needed for the survival of business. 
The geeks had always been the troublemakers for the staid business culture 
but now the firms really needed these electronic wizards to be happy or at 
least somewhat content with their lot. 


Businesses realized that prior to the lockdown of their technology workers 
there existed a modicum of experimentation, freedom, and creativity 
inspired by less dictatorial policies. What was needed were policies, 
processes, tools, and leadership styles that once again promoted creativity, 
some freedom, some experimentation, shorter integration cycles, but all 
within a dominance structure familiar to a capitalist corporation. 


Many ill-fated processes came and went until organizations took a second 
look at the Agile processes like Lean. Lean became an early hit. Scrum was 
another Agile process that was also very popular. These Agile processes 
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would promote a somewhat freer environment that was separate and distinct 
from the rest of an organization’s hierarchical control structure. This was the 
perfect compromise that allowed firms to maintain a fair amount of control 
over their employees while also giving their troublesome technology folks 
the much need autonomy that would inspire them to innovate. 


synchronized Technology Transformation Across Existing Units 
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Agile Process Implemented Across Departments/Units/Silos 


The technology staff of many firms were enthralled to learn that they were 
to be given back some control over the development, testing, and integration 
cycles. Within the more progressive organizations, the technology staff, in 
some cases even the control structure of the firm itself was changed from a 
vertical top-down autocracy to a flattened, cooperative, and change 
adaptable set of collaborative teams. These collaborative teams even had a 
structure, processes, daily communication, and an iterative mandate to 
accelerate change with the new Agile processes being utilized by many 
firms. 
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Stimulating innovation was not the primary objective of businesses faced 
with a hypercompetitive, continuously changing business environment, and 
web traffic unimaginable just a few short years ago. Most firms would have 
been satisfied with just ramping up the productive output of their technical 
staff. Inspiring creatively within their technology architects, developers, and 
the newly emerging site reliability engineers was a nice outcome of the 
flattened Agile liberty, but for the average business this was not essential. 
They just wanted to keep up - not be left in the dust by their faster and more 
nimble competitors. 


For the technology companies and now the ever increasing number of tech 
startups, empowering an innovative culture of freethinkers was essential to 
the survival of their business. Now the question swirled around how much 
innovation was necessary within each type of business. Maybe just allowing 
the interplay of creative juices not constrained by corporate directives was 
enough change? Only forbidding actions detrimental to the continued 
viability of the corporate entity was ultimately all that was needed. 
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Managing Innovation by Autonomous Teams 


With the enhanced creativity being a byproduct of the flattened interplay of 
Agile teams was it now possible to channel the laser-focused goals and 
objectives important to an organization to these empowered technology 
cocoons and have the results the firm wanted spit out the other end? Could 
managers better aligned to business outcomes just tell the technology teams 
what the organization wanted at a high enough abstract level without going 
into excessive details on how the technology experts were to fulfill these 
basic goals? 
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By properly articulating the User Stories, creating the associated Use Cases 
of a few high level organizational objectives the product owners, users, and 
the team(s) can self-direct their energies accordingly. An enterprise level 
architect can produce high-level architectural artifacts that break down the 
context barriers using Domain Driven Design (DDD) after consulting with 
the business domain experts and elaborately iterating through the User 
Stories across fully engaged collaborative teams. This is an enlightened 
approach that can be the outgrowth of infusive liberty empowering an entire 
organization. 


But before this free spirited unencumbered teamwork can begin there needs 
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to be real teams not stifled by organizational ineptitude and autocracy. In so 
many organizations there still exist many silos that have handled projects 
not products and therefore have a sprinkling of experts throughout the 
organization that need to come together in cohesive cross team relationships 
- at least initially. Once the conditions are ripe for pulling these experts from 
their current project focused teams and sealed up silos into teams that are 
focused exclusively on the product only then will more progress be possible. 


Additionally, tearing down all artificial hindrances to continued team 
progress on creating and maintaining their prospective products once the 
teams are in place will be an ongoing challenge in businesses mired in 
dictatorial convolution. Devising the organizational environment that is 
more cooperative and less autocratic will go against the capitalist grain for 
many a firm not comfortable with handing power over to any group of 
employees. 


Corporate success in the 21st Century is dependent upon releasing the tight 
grip on the reins of control and letting the business become a self-directive 
antifragile entity that grows stronger through positive emergent behaviors 
that are emitted from the business interacting with its customers, employees, 
and its external environment. 


To have absolute control over anything is impossible - anathema to the long- 
term survival of the controlled entity. How can all participants in the success 
of a business work together with shared responsibility and across the board 
equitable remuneration? Is there a technical rational for driving such a 
revolutionary cultural shift in 21st Century firms? What is the new technical 
philosophy that is fusing with the standard command based organization? 


The technology and business experts across the specializations and 
segregated distinctions that businesses have forced upon technologists must 
work together in a Microservice Architecture focused organization. 
Everyone with a stake in the outcome of technology products should be 
involved in the elaboration process that enhances the understanding of 
current and/or future systems. Business survival in the 21st Century rests 
upon how rapidly the Microservice Architecture philosophical constructs of 
respect for uniqueness, independence, adaptability, antifragility, and 
cooperation are embraced. 
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There can be no bystanders in a progressive business culture that 
understands the importance of diversity but also the importance of each 
associate’s positive contributions towards the success of the firm. Those 
who do not want to positively contribute to their firm’s success in achieving 
the goals of the cooperative venture are not welcomed in the new modern 
firm. 


From a technology standpoint the same values that are embraced across the 
organization must also be respected by the technologists. Those who have 
no vested interest and are not positively contributing to the design, 
development, maintenance, and administration of the new system or a 
microservice for the duration of its existence should not be involved - they 
have no skin in the game. They are bystanders relegated to the bleachers. 
Too long soaking up the sun in the bleachers without any on the field game 
play should relegate any individual like any microservice to forced 
obsolescence. 


Suffice to say that empowering teams to handle the entire spectrum of 
responsibilities necessary to ultimately place a technology product into 
production is all about letting the requisite experts do what they do best - 
their complex jobs - free from interference from well-meaning but typically 
misinformed managers. Pontificating disconnected managers or other pure 
business controller types who only have a rudimentary knowledge of high- 
tech tools and processes have absolutely no place in the ‘tool shed’ or 
‘clubhouse’ of the Agile teams. These bean counter drill masters should let 
the real software developers, business analysts, operations sysops, architects, 
and others do their jobs without excessive interference. That way, the 
resulting applications and systems will not become some messy dung that 
smells of overt micromanagement. 


Creative individuals operate best, are their most ingenious when left to their 
own devices. Hierarchical control structures are constantly slowing down 
those of us who are inventive. Firms with their endless interference, red 
tape, and roadblocks all meant to keep layers of management apprised of 
what the divergent right-brained flighty thinkers are doing only inhibit our 
productivity. The interruptions, over-the-top processes, emails, meetings, 
and all the rest of the management minutia translates into less productive 
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and creative teams. Layers of corporate processes, regulations, and 
management ineptitude impede the creative inspiration of those most valued 
for their insights. 


This corporate insanity, the many linkages and probes sunk deep into the 
flesh of each business just to keep tabs on the employees - all the vertical 
control structures from the horse and buggy whip-in-hand despot century 
were about to hit a brick wall. Top down, tightly screwed, inflexible, and 
repressive forms of organizational control were like adding water to the oil 
of 21st Century business. These overt club-in-hand control devices were just 
repulsive, a repellent of ingenuity and progressive corporate growth in the 
new era of openness and inclusion. 


The ‘Change-Makers’ were again invited back into the decision making 
arena of the firm where technology knowledge reigned supreme. A 
semblance of sanity returned to the development, deployment, testing, and 
operations silos now coming together in teams working on products not 
projects. Most organizations were finally coming to the realization that the 
internal and external environments that also included the business landscape 
had metaphorically shifted back to the kinder-gentler free-spirited time 
before the invasion of the monoliths. The whip in hand overseer focused era 
was coming to a close and the corporate iron-curtain was coming down. 


“Change-Makers” who had been outside the typical business were 
envisioning a plethora of yet to be dreamed marvels. Released from the tight 
grip of top-heavy companies allowed multitudes of creators to come 
together to form new working arrangements that would significantly disrupt 
the status quo. This was to be the equivalent of the “Age of Enlightenment” 
- a flotilla of small but nibble contributors free to just be creative. Uploading 
code and ideas every second - a great surge of humanity expressing its 
innermost desire to shape the world with the hands and skills of the many, 
not the few, were now hyper-creating ingenious technologies. 


These would be technologies that leap-frogged further than anything thus 
imagined by the buttoned up businesses. Technology preeminence and 
dominance would now become the mainstays of a breed of technologists not 
satisfied with the status quo societal structures. They were reinventing the 
firm in their own freewheeling likeness. The new powerhouses of 
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technology preeminence would be less structured and much more flexible, 
dynamic, creative, and collaborative. Without silos or roadblocks that would 
inhibit progress or the next big technology idea these new businesses would 
slowly eat away at the market share of the dominant companies and in some 
cases simply blow them away. 
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The Open Source Revolt 


Progress is a byproduct of built up historical imperatives. Epochal 
dynamism that shifts humankind into new modalities is a flood of 
progressiveness finally allowed free expression and general support. Once 
the Agile methodology and the associated empowerment of former 
production oriented workers were let loose there would be no stopping its 
spread - especially into technology startups hankering for ubiquitous 
communication pathways and supercharged idea generation. 


Production dazed technology workers; the cubicle deadened developers 
getting a taste of an enlightened business subculture in Agile started 
dreaming of charting their own destinies with other techies. By expanding 
the Agile processes throughout an entire organization not centered upon 
profit - at least not initially - these lovers of technology could experience the 
thrill of creating something where nothing existed before, they could dare to 
dream big dreams. 


Online technologies were advanced enough to allow many thousands the 
opportunity to create cooperatively. Source control tools made collaboration 
between these legions of visionaries possible. With the flood of ideas, 
software, concepts, non-constraining processes, and many an offshoot 
product or service coming from this mass of human ingenuity every creation 
started to feed upon the next creation. Tools like git, Docker, and many 
others just kept reinforcing the technical prowess and genius of more and 
more individuals collectively driving the most explosively creative time in 
history. 


Typical management and process heavy business could not compete with 
what was now called the “Open Source Community”. The arthritic business 
blobs were ill-equipped to allow unconstrained communication across a 
multitude of departments, branches, groups, or the more appropriately 
termed many silos that inhibited the free flow of ideas and change. 
Succumbing to the “Open Source” bright morning sunshine like so many 
zombies withering away, many of the old-school firms silently crawled to 
their graves. 
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Even though some of these same businesses had experimented with 
empowering their technology staff they could not throw out the business 
dogma, a decades old way of engaging in commerce that required direct 
line-of-sight control over their employees. 


What would happen if they mirrored the organizational structure of these 
new startup “Open Source” shops? Many a manager, director, division head, 
and silo dictator would lose their jobs. Then how could they be sure the 
castle dwelling upper executives wishes would be fulfilled without 
question? 


Even if the existing structure was detrimental to the organization no one 
would dare question it from inside an autocracy. Everything would drift 
along like it always had until some new “Open Source” firm bought out or 
stole all the business away from the dinosaur. Did not the current capitalist 
societal model depend upon unquestioning, uncritical, and very productive 
employees? All those divergents stirring up trouble in the “Open Source” 
community were a threat to the established order. The sheltered executives 
could not believe that a few hellcat startups would topple them from their 
thrones but those working in the trenches saw the writing on the wall. Times 
were changing - and fast. 


The sacrosanct bottom line in capitalist organizations always pushed 
management to shed costs across the endless layers of the corporate onion. 
Free was nirvana to businesses wanting to get something for nothing so they 
could bulk up their profit margin - that all important bottom line. Even the 
most fanatical capitalists could not resist the draw of ‘free’ software, tools, 
and other products and services pouring in from the “Open Source 
Community”. This was just too irresistible, no upfront costs, a beautiful 
oasis for the short-term oriented, quarter driven, and myopically tuned 
corporations. 


But could the “Open Source” firms exist outside the dominant societal 
structure that was a capitalist economy? How would they perpetuate their 
continued existence if they did not generate some money? There had to be a 
way to stay true to their core beliefs of community cooperation that was the 
underlying source of their innovative products. Being the patsies of 
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companies wanting a free ride on their backs left a bad taste in their mouths. 
What was the model that would be a merge of both limited capitalism and 
collaborative innovation? 


“Open Source” firms faced the harsh realities the even they had to pay rent 
on space, lawyers, marketers, software, website maintenance, and many 
residual necessities. Even cooperative businesses needed regular infusions 
of revenue to keep the “Open Source” happy coding ‘frat house’ open. 
There was just no way to separate an organization or oneself from the 
society that they must interact with on a daily basis. No matter how many 
developers devoted their time and energy to the product by busily merging 
their code into source control, some expenditures of the cooperative 
endeavor just had to be paid for outright. 


Properly funding the “Open Source” firm meant accepting a middle ground 
stance between the original non-profit cooperative group and the pure 
capitalist profit oriented company. Coming to the realization that revenue 
had to be generated was a hard pill to swallow. The unfettered originality, 
free-spirited developer comradery, ease of contributing to the community’s 
source control repository from anywhere across the globe, few attached 
strings, little to no layers of bureaucracy, and all that had become typical of 
a technical cooperative had to be maintained. Somehow, a derivative model 
must be found that would generate sufficient revenue to keep the doors 
open. 


Charging for an enterprise version, support contracts, any additional set of 
features or benefits that could be provided by the “Open Source” firm was 
the way out of their revenue jam. These organizations could maintain the 
collaborative flattened very productive, relatively process free, and 
respectful technology focused atmosphere and culture only minimally 
contaminating it with revenue streams from corporations needing more than 
the base product and services. 


This new revenue model for the “Open Source” firms was perfect because 
those not able to pay would still get the base product while the enterprise 
full-featured version was paid for by firms willing to fork up the cash. 
Software freely distributable to the broadest diverse group of users could 
still be maintained in the form of the basic product versions. 
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If the contributing developers did get rich from their creating something 
many corporations were willing to pay dearly for - so be it - this was just a 
byproduct of doing what these techies enjoyed the most - expending mental 
energy on solving problems that seemingly had no solution or coming up 
with a product that no one realized they needed. 


Flattening the organizational structure, integrating and involving a dispersed 
and diverse community of developers in the creation of a software product 
free from undo corporate oversight, layers of control, short-term oriented 
demands - all these benefits of inventing a revolutionary collective group 
structure takes money. The beauty of the new funding model was that it did 
not corrupt all the lofty ideals that the “Open Source” firms were founded 
upon. It was obvious to all those involved in the many “Open Source” firms 
that having an adequate amount of revenue flowing into the collective to pay 
the bills was essential to the continuity of their businesses and the new 
revenue model worked marvelously. 


The pure egalitarian collective model of global engagement might have been 
unsullied by a trickle of cash entering the “Open Source” organization but 
when a surge in enterprise product and service orders from software that 
businesses just could not do without hit the bank accounts of the principle 
software coders all the torn jean, black tee-shirt, utilitarian living, went out 
the window. BMWs, luxury homes in exclusive communities, yachts, and all 
the trapping of the nouveau riche techies were now within reach of those 
who contributed the most to each “Open Source” firm’s success. 


After their companies went public the open-sourcers entered the ranks of the 
super-rich. They had book deals, trophy wives, speaking engagements, and 
castles that sultan’s envied. Bohemian lifestyles, grand pronouncements of a 
new age outside the commercialism that was destroying the technology 
industry, all this might have been fine when these well-meaning creators got 
together to work on a solution to some obscure problem that was not even 
on the radar. Now the money was rolling in - flooding the accounts of 
former full-spectrum divergents no longer interested in pizza, coffee, or the 
occasional donut. These tech giants now enjoyed feasts in their grand dining 
rooms with adoring guests. 
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These first “Open Source” collectives like JBoss and a few other well- 
known technology companies had derived a blueprint that any future “Open 
Sourcers” could follow. Success was now within reach of many more 
divergents, those focusing on creating, generating ideas, and tearing down 
needless barriers to human ingenuity. 


Literally, anyone could get together with others anywhere on the planet to 
build the next great framework, platform, website, or whatever popped into 
someone’s brain. The collective group model had proved that “Open 
Source” worked. If you had a software tool just load it up on an Apache 
project, or start your own website and collaborators would flock to it in the 
droves. There would be virtual lines of coders waiting to contribute on the 
next great idea. 


Typical straight-and-narrow minded traditional firms were placed on notice. 
There model, at least when it came to generating creative ideas, software, 
technology, or any highly skilled and intellectually derived endeavor could 
not compete with the “Open Sourcers” - these nimble and super adaptive 
Borg-like ‘houses’ of dynamism were continually reinventing themselves. 


Technology giants like Google, Amazon, Netflix, Facebook, Twitter, and a 
few others comprised the first wave of progressive and insightful dynamism 
across an industry that had luxuriated in a glow of self-admiration for so 
long that it had become complacent. Emulation of the “Open Sourcers” was 
now in vogue. Many technology companies and some mainline non-tech 
firms were now attempting to dissect what invigorated and propelled these 
tiny specs of tightly woven communalism to take up dominant positions 
within the technology industry. 


Their experiments with corporate culture pushed the boundaries of the status 
quo into the stratosphere and in some cases blew all barriers and constraints 
into a million pieces by rewriting how their primary business operated and 
dealt with a now more sophisticated group of user customers. 


Not happy with depending entirely on “Open Source” software Google, 
Amazon, Netflix, Facebook, and Twitter started writing their own custom 
software to deal primarily with a scale that had not existed until recently. 
Realizing that the success of their businesses was directly tied to how 
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thriving the entire technology industry was these giants fed their creations 
right back out onto the Internet free for anyone to use including the “Open 
Source” communities. These deep pocketed tech behemoths understood 
their interconnectedness to the healthy “Open Source” idea hotbed that they 
themselves originated from many years ago. If adding their creations to this 
‘greenhouse’ could spawn more innovation this would in the long run 
benefit everyone - a self-perpetuating feedback loop of inventiveness would 
be boosted with high octane well-funded innovations. 


All the laggards in the technology industry and across other sectors were 
quick to comprehend that if they did not appropriately adapt to the new 
competitive landscape that required a certain minimal level of technical 
competence they may become irrelevant or worse yet a nonentity - a 
Wikipedia entry with an end date. 


OF 


What Is Inspiring the Evolution of a 
Microservice Architecture Orientation? 


Shifts in paradigms never originate from a single event but are the result of 
multiple changes merged and transformed in environments conducive to 
their insights. Internal and external cultural ground must be fertile enough to 
support the monumental reorganizing of how human being’s comprehend 
their world. We never end up substantially reworking something just 
because it entails some emotional stimulus. Dramatic changes in all spheres 
of human endeavor occur because of a need to fix something — a desire to 
make our lives easier or more rationally ordered. 


Similarly, the Microservice Architecture thrust did not happen because 
someone decided they just wanted to disrupt the proverbial ‘apple cart’. On 
the contrary, microservice architectural insights were the result of the 
dysfunctionality of corporation hierarchical command structures that had 
been infused into technology. 


The monolith large scale systems were failing for the same reasons the top- 
heavy gigantic firms were lurching along. They were both unable to adapt to 
a rapidly changing environment. These monoliths were just too tightly 
coupled, functionally integrated across all the compartmentalized packages, 
components, and other structures designed to keep some semblance of order. 
For order was of paramount concern in a heavy handed monolith enterprise. 


Large monolith organizations had reached the limit whereby they could 
quickly adapt, plan, organize, and marshal all the resources at their disposal 
in coordinated actions. These obese frameworks — the monolith 
technological beasts, were the offspring of plodding along organizational 
laggards. Monoliths were unwieldy like the firms they were hatched from - 
maintaining and making simple changes took many weeks and sometimes 
months of planning, development, and testing that finally culminated in 
ceremonious production deployments. 


The new world was inspired by instantaneous communication across the 
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Internet within social networks, a more collaborative, cooperative, 
community based global culture that made the monolith both the 
organizational and technology versions obsolete, they were both relics of a 
bygone past. These highly integrated, siloed, tightly fused, and corpulent 
lumps of hierarchy were easily destabilized anachronisms; both the societal 
and technical variants were doomed to failure. 


Discontinuity in cultural models always resolves to some semblance of 
continuity, a reasoned outgrowth of what works. Technology being just an 
outgrowth from a societal system reflects the society that it is embedded 
within regardless of whether this cultural inscription is progressively 
democratic or repressively authoritarian like the crumbling hierarchical 
organizational monolithic. 


Culture shapes our day to day interactions at various levels. We are 
personally who we are partly because of the cultures that we are engaged 
within. This individual affinity for certain cultural identities is transferred to 
the organizations we are cleaved to for our sustenance, satisfaction, and 
advancement. If we experience cultural discontinuity, a feeling of not 
belonging or fitting in with a culture, even a work culture, we will typically 
attempt to locate another culture that is more agreeable to our specific 
personality traits. 

Even the processes that order our day-to-day lives both at work, home, and 
at play — how we organize our ongoing endeavors, is a direct reflection of 
the changes transpiring all around us — the continual amalgamation of 
events that shape who we are and how we devise our daily activities. 


Culture is a constantly changing dynamic of the human condition. Our 
various interactions with one another are always in a state of flux. Recently 
because of the Internet and our heightened online activities in social 
networks and via other forms of instantaneous electronic global 
communication, the cultural dynamic that was previously gradually 
assimilative is now chaotically hyper-dynamic. 


When a dichotomy exists between the outside general society and inside 
corporate cultures the external will always prevail in the long-run. This is 
because no matter how dictatorial the internal work environment is the 
views and beliefs inspired outside, if free to form and evolve will gradually 
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transform the internal culture of any organization. Once the leak of the 
external environment satiates the desires of the internal conscripts, all bets 
are off, the organization will start evolving to conform to its evolving 
external environment. 


We are witnessing just such a transformation of the business organization 
from a hierarchical tightly fused monolithic autocracy into a more horizontal 
and less autocratic organizational structure. The conversion from monolith 
design patterns to micro collaboration across professional disciplines is 
inspiring decentralized organizational structures. These new organization 
structures are being activated by a loosely-coupled unfolding micro 
paradigm shift in the technology cultural substrate. 


Evolving power flattened organizations are replacing their monolith systems 
with a Microservice Architecture and associated agile processes that align 
with the decentralized metamorphism engulfing them — the 
democratization of bloated corporate autocracies. Monoliths across all 
human societal and cultural substrates are withering away. The newly 
reformulated human articulations emphasizing unique granularity are now 
transcendent. 


Large is now synonymous with inherent fragility, an inability to adapt to 
continuous internal and external environmental stressors. Nimble 
organizations, even governments, are those that are small like startups. 
Adaptable governments are small and more local - directly in touch with 
their constituents. Like the cantons of Switzerland that are tiny often 
seemingly very agitated and ineffectual, but it is this steady stream of 
‘noise’ that is like a release value lessening the probability of a major blow 
up - this government is antifragile (Nassim Nicholas Taleb) - gets stronger 
from stressors. 


Small is better, more aligned to individual needs, unique, self-contained, 
self-supportive, and flexible. These new micro corporations, governments, 
and microservices not shielded from environmental stressors are inherently 
antifragile. Antifragile and fragile are incongruent, like matter and 
antimatter they cancel each other out when placed together. Therefore, the 
antifragile smaller human structures both tangible and intangible that are 
able to strengthen and rapidly adapt to internal and external stressors are on 


40 


the rise. The large, lurching, process heavy, hierarchical societal constructs 
are in decline. They are just bygone shells of their former glory. 
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Microservice Architecture Is an Extension of 
“Open Source” Neighborhood Philosophy 


Microservice Architecture encompasses not just the technical aspects of 
designing a resilient, adaptable, secure, and scalable framework but also 
ensures its successful implementation by infusing it within an organizational 
structure that embraces the microservice philosophical paradigm. Simply 
providing an organization with the technical understanding of what 
comprises a Microservice Architecture and all the base technologies that can 
be utilized is a recipe for failure. 


Microservices cannot simply be plugged into an existing 
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of Microservicé Architecture processes and technologies 
that form a holistic collaborative ecosystem 


Typically, the business environment that contributes to the successful 
implementation of a Microservice Architecture is not found within most 
hierarchically organized firms. This technology is light years away from the 
dictatorial head-down do what you are told - ask no questions cultural 
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template. 


Each microservice is synonymous with an individual. Both the microservice 
and an individual are unique self-contained and expressive units best 
integrated within an orchestrated horizontal interface. From the interactions 
of many individuals or microservices emerges a concerted set of behaviors 
that are deterministic or nondeterministic depending upon a multiplicity of 
environmental interactions. 


Orchestration is not autocratic rule, but an adaptable and suggestive set of 
goals and outcomes that individuals and microservices may resolve to 
during their interactions with their environments. Overt control is out. 
Cooperative group goal achievement is in. 


Orchestration can be achieved in a Microservice Architecture with a 
Microservice API Platform Management/Gateway (MAPI-PMG) comprised 
of an API Manager, API Gateway, Developer Portal, and Administrative 
Portal. The MAPI-PMG can effectively coordinate microservices into 
meaningful combined system behaviors. Like the laws of our human world 
that keep us from straying off onto pathways that may spawn emergent 
group and individual behaviors that could be self-destructive a MAPI-PMG 
keeps the microservices coordinated - orchestrated towards achieving 
behaviors consistent with the requirements of the application. 


Orchestration of micro units whether human or artificial like microservices 
must still adhere to some form of minimal process restraints or else anarchy 
is the unintended outcome. Granted, over blown processes, those that strap 
us and our systems down so tightly that nothing positive can be achieved are 
not desired. Light, loose, broad goals and outcomes can be best realized in 
small groups that meet regularly without the need to maintain burdensome 
records or adhere to a ritualistic agenda. 


Cooperative, iterative, collaborative, non-stove piped, openly progressive, 
and Agile process work environments that value the individual over the 
corporate entity are typically the most successful in implementing a 
Microservice Architecture. They have just the right amount of direction and 
process requirements without destroying the free interaction of the 
participants with lockstep tasks. 
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Top-heavy silo infused organizations that refuse to allow freedom of 
expression to reign supreme will just produce a distributed mesh of 
interconnected process spaghetti. These paragons of heavy-handed 
dictatorial rule within a bloated monolith corporate structure will never 
understand the benefits of moving to a leaner decentralized operational 
model. Being adverse to all that Agile stands for makes these lurching 
behemoths ripe for creative destruction. 


Microservices are never implemented or utilized successfully in 
isolation, they are integrally tied to: 


Empowered teams that are not under the yoke of corporate command 
influences emanating from above can nimbly adapt to their rapidly changing 
environments especially when utilizing a light-process like Agile to 
coordinate their efforts. Teams that are comprised of professionals who will 
not and cannot cooperate because of undue interference from above or 
across still existing silos will be ineffectual in spurring real substantive 
progressive changes leading to anything meaningful. The same worn out 
paths will be followed and similar technologies to those that are currently 
utilized will be investigated, resulting in no objective identifiable positive 
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change being achieved. 


Real Agile inspired lean teams are given complete responsibility over not 
more than ten microservices that they own in a DevOps shop that has 
operations professionals dispersed throughout the teams. Each team is an 
empowered multidisciplinary group of teammates. Microservice architecture 
is a people-first not corporation or management-first technology facet. 
Without this orientation being promoted at all levels of the organization, 
failure will be the only outcome of trying to implement a Microservice 
Architecture. 


As an extension of the “Open Source” philosophy that values the 
cooperation and collaboration of all equally respected team members within 
lean minimalist organizational structure creativity is not snuffed out with 
over rationalization. Focus is not on building a crystal palace but a 
neighborhood of well-constructed unique homes that together comprise a 
community of shared purposes. Each microservice is therefore like a single 
house whose occupants add value to the community by engaging in their 
chosen profession by producing tangible products and services essential to 
the vibrancy of the community and surrounding neighborhoods. 


45 


Essential to the Success of a Microservice 


Architecture 


Small sized microservices that do only one thing well 

HTTP/REST enabled JSON messaging 

Each microservice is context bounded 

Design microservices to be capabilities-centric not CRUD (create, 
read, update, and delete) data conveyances 

Data storage that avoids data sharing between microservices is 
possible with event sourcing and CQRS - each microservice can be 
very tiny just managing a single event - but use only when necessary 
Microservices are autonomously developed, managed, and 
maintained 

Independently deployed microservices 

Each immutable microservice should be containerized with Docker 
All microservice dependencies are internalized 

Use a MAPI-PMG like Kong or Tyk 

No across-microservice dependencies (only if required use Service- 
Mesh with Side-Cars) 

Self-contained microservices with their own micro-server, 
implementation, and datastore 

DevOps - CD, CI, CDeploy build, release, and deployment 
automated processes 

Business environment that is cooperative, collaborative, equitable, 
decentralized, and change adaptable 

Organization embraces the Agile process 

Teams should have no more than 8 - 10 members 

Each team owns a collection of microservices 

Systems of varying complexity can be created with a collection of 
microservices 

Avoid non-essential complexity that can negatively impact scope, 
scale, and safety 

Share-nothing and distributed workflow Microservice Architecture is 
not well suited for sequential transaction implementations but can 
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still be accomplished by using the Sagas approach 


e System monitoring usually handled by a MAPI-PMG like Kong or 


Tyk 


Every microservice should be its own autonomous unit with a micro server, 
data source, internal implementation dependencies, and immutable Docker 
container. A single team should own each microservice with no cross-team 
responsibilities for any single microservice. Unique stateless microservices 
are continuously built, deployed, and released into an automated CD, CI, 


and CDeploy DevOps development and operations collaborative 
environment. 


Results 


Shortens time 


DevOps from dea 
conception to 
Automated testing deployment 


Operations representative on each microservice team 
Open communication channels across organization 
Automated deployments 

Automated production releases 

Continuous monitoring 

Unobstructed visibility all the way to production 
Meaningful alerts Speeds along 


100’s of daily 
production 
releases 
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Never save the state of an entity, component, or anything else ina 
Microservice Architecture. Saving the state of any part of a Microservice 
Architecture especially the state of individual microservices impedes the 
ability to maintain loose-couplings within this type of system. This is a path 
of no return leading to cross-dependency complications that induce tangled 
logic flows that reduce scalability and become difficult to unwind. 


Your goal is not to replicate a monolith monster in the form of a brand new 
distributed monster. Nothing will be accomplished if the complexity of a 
monolith is just transferred to a tangled mess of 100s or 1000s of 
microservices. That is why it is essential that each microservice maintains its 
own unique and distinct identity not munged up with dependencies from 
across the system. 


Simplicity is the underlying philosophy of a Microservice Architecture 
where each microservice is a unique self-contained, self-sufficient, discrete, 
and indivisible unit that does not handle a multitude of messaging tasks. 
Every microservice should be immutable, if it needs to do something that is 
even slightly different from its original single-purpose task it should be 
replaced by an entirely new microservice. Never hesitate to dump an 
existing microservice in the proverbial trash bin, these are highly 
replaceable entities. 


Every aspect of the design of a Microservice Architecture should be founded 
upon the simplest least decomposable technologies. Building up layers of 
complexity in this type of distributed micro-componentized architecture will 
only make the maintenance, debugging, understandability, and adaptability 
of the system very challenging. 


For the sake of practicality and simplicity a microservice should use the 
HTTP application protocol to transfer JSON or YAML messages that adhere 
to the REST messaging protocol. Never munge RMI protocols inside the 
header. Remember that simplicity, ease of replacement, and especially basic 
message transference are the key to maintaining the uncomplicated 
practicality of a Microservice Architecture. 


The Microservice Architecture mindset is centered upon a minimalist’s 

outlook on life - needing and using only what is necessary to achieve the 

primary goals or meet the requirements. Only code what is needed and 
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always strive to continuously and iteratively simplify the entire system. Tear 
out any extras or abstraction layers that are not absolutely necessary. 


Live and breathe the Keep-It-Simple principle. A life of simplicity 
especially within the technology arena will help you to roll with the punches 
of a very turbulent world. Sleep will always come easy to those not troubled 
by over complexity. Elegance is an art form that is steeped in simplicity. 
Learning this art is more about when to use the technologies in your tool belt 
and when to leave well enough alone. 


Lucius Annaeus Seneca the father of Stoicism believed that we should not 
become too attached to our possessions, only keep what is necessary and not 
acquired through debt. He also believed that mentally writing off our 
possessions - a process of disentangling ourselves from worrying about 
keeping them - freeing our minds of worry about things we really do not 
need prepares us for the volatility that the world will surely trample us with, 
if not today, then tomorrow. 


From a systems perspective we should not become too dependent upon any 
part of a system and only keep components or microservices that serve a 
purpose today not someday in the future. The future over engineered parts of 
our system becomes technical debt that will keep us up late at night. What 
do we absolutely need to have within a system? Toss the rest out! 


Eliminate the downside or harm from fate by not keeping useless code 
clogging up and lying around in an application. Maintain the upside, by 
having a more responsive, antifragile, easily maintained, understood, and 
easier to replace set of microservices all within a lean-and-mean elegant 
system. 


There exists an upside - downside disequilibrium. The objective is to 
maximize the upside by not creating systems that are fragile - vulnerable to 
real world disturbances. Vulnerable systems are those that have many points 
of failure - many more than is necessary. 


The new technical discipline of Microservice Architecture is all about 
envisioning, designing, and developing systems that are antifragile, 
composed of many microservices, each one not so important that if it was 
lost would not disable the entire system. Far better than being resilient, the 
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system instead becomes stronger. A better system would emerge after a 
team’s almost instantaneous correction for the stressor(s) in a DevOps 
moored shop and the system firing built-in emergent behaviors that promote 
a general improvement through adaptation of system characteristics and 
dynamics. 


Also, periodically, or when coding a new microservice, we should revisit the 
other microservices to determine if any of them can be eliminated or put on 
a diet of code reduction - eliminating blocks of useless, no longer used, or 
never used code. Like Lucius traveled light with only a towel to rest his 
head on and a few meager possessions. Similarly, our systems codebase 
should always be trim, and ready for the vicissitudes of an unpredictable 
world. 


Constantly iterate over the code, in what can be called Iterative Relevance & 
Simplification Analysis (IRSA) in an attempt to keep each microservice 
focused, lean, simple, and relevant to its single-purpose task. This 
refactoring must be embedded in the development process, something that 
becomes a regular part of what can be termed creation and destruction. 


From my experience all code starts out relevant to the task it is intended to 
accomplish but over time becomes irrelevant simply because the world 
changes daily. Our code remains static especially if we do not regularly visit 
it to ascertain its relevance. That is why we must exercise constant vigilance 
and always question why this or that is done the way it is done - coded to 
produce the particular outputs for another component, entity, or system. 
Software development is never a finished product that can be neatly placed 
upon a dusty shelf. It is a ceaseless evolutionary process that involves 
unending retrospection and inspection. 
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Iterative Relevance & Simplification Analysis 
(IRSA) 


Microservice 


Relevant Irrelevant 


With the passage of time a microservice can become gradually irrelevant to 
its intended single-purpose task. That is why as a matter of ingrained 
process all code should be iteratively analyzed to determine if itis still 
relevant to its intended task and as simple as humanly possible, 


Stay away from trying to create perfect code libraries and big just for the 
sake of just being big. This line of ‘reasoning’ only leads to spaghetti code, 
over-engineered complexity, maintenance headaches, and originates from 
those who want to impress the world with their programming skills. 
Microservice architecture is a minimalist’s dream in its simplicity. It is not 
another latest fad nightmare for developers forcing them to keep their spare 
futon at work. 


From a design standpoint, limit the implementation of a microservice to a 
single well-defined Domain-Driven Design (DDD) bounded context of an 
application or system. Capabilities-centric microservices with context 
delimitation ensure that small and simple microservices are not just dumb 
CRUD conveyances between a datastore - they can be effectively utilized 
internally and/or externally. 
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Tying microservices to CRUD data transmittal destroys the autonomy and 
independence essential to a Microservice Architecture design pattern. Each 
microservice that is inextricably tied to a database schema for the purpose of 
aping data point messages through a ‘pipe’ between a caller and a database 
are inflexibly shackled to datastore subservience. Freedom, the ability to 
change, refactor, add, or remove microservice component functionality - the 
building and deploying of these distinct units of utility must not be 
negatively impacted by fusing each microservice to CRUD slavery. 


Even though each microservice will have access to data it is important that 
this data is not within a schema that is used by another microservice or any 
other application or system. Data autonomy, the ability to change the 
structure of how data points are maintained or accessed is handled 
differently by each datastore. An RDMS has a schema of tables, keys, and 
fields. NoSQL Cassandra has a key store. Each microservice can maintain 
data independence even though it may use the same datastore for every 
microservice. This can be done by having no two microservices sharing the 
same schema, key store, or whatever the delimiting entity is for a particular 
datastore. 


More important than maintaining microservice data independence is not 
binding microservices to a single language and framework. For instance, the 
Java language Spring libraries or Java EE framework and all the baggage 
that these obsolete, over engineered monstrosities dump into a clean and 
elegant Microservice Architecture are nothing but an obscene corruption of 
what embodies a Microservice Architecture. 


Implementation of a microservice is programming language agnostic. Use 
the language best suited for the task. Keep each microservice 
implementation free of do-everything monolith heavy languages and 
frameworks. Clean, light, elegant, independent, polyglot microservices are 
easily maintained, deployed, and replaced. Stick with these basic and simple 
microservice implementation guidelines and do not get side-tracked down a 
nasty weed overgrown path of needless framework and language 
complexity. 


Microservice Architecture is more than technology; it is a mindset, a 
philosophy rooted in freedom and minimalist simplicity to reduce 
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complexity, a desire to continually demystify and simplify the unfathomable 
or incomprehensible. The regular iterative search for component 
independence across a system of unique cooperating microservice 
‘individuals’ is not solely rooted in technical ability but the free spirit of 
unconstrained humanity. 


That is why it is extremely important to stay clear of all the stone age 
monolith frameworks, tools, and all the other extraneous layers of 
complexity that are typically marketed and promoted by large technology 
corporations or by techies unable to break-free from huge unwieldy gigantic 
parasitical frameworks that only suck the life out of creative technologists 
turning them into mere production Droids. 


Microservice Architecture is that rare alignment of goals between the purely 
innovative technologists and cost conscious business professionals. Not only 
does this architectural design pattern save companies small fortunes but it is 
a chance for production oriented technologists to unshackle themselves from 
extreme process slavery and all the tightly twisted complexity resting in the 
“Big Ball of Mud” that was the monolith dungeon of the application server 
framework prison. 


Individuality is at the heart of a Microservice Architecture that evolved from 
the “Open Source” revolt to power for power’s sake and the associated loss 
of efficiency, dynamism, creativity, and the stifling of the human spirit. That 
each of our voices when combined thoughtfully can become a chorus of 
melodious beauty. Likewise, a microservice is a direct response to the desire 
of technologists to be expressive, unencumbered by needless processes and 
control hierarchies imposed by those with no ‘skin in the game”. 


Every microservice is therefore like a unique individual contributing to, but 
not subjugating or being subsumed by others. Just like an individual’s 
biological existence is determined by internally prescribed cellular processes 
- the internal implementation of a microservice has all the dependencies 
necessary to support its technical ‘life force’. 
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Microservice API Platform 
Management/Gateway (MAPI-PMG) 


Bona-fide MAPI-PMG orchestration management gateways like Kong and 
Tyk were built not by control oriented but an “Open Source” flat startup free 
spirited culture that values cooperation and collaboration. That is why Kong 
and Tyk do not send their spider webs out to ensnare zombie services, 
subsystems, and processes to be micromanaged by some complex yet fragile 
central control core. 


MAPI-PMGs conceptually invigorated by unrestrained creativity are not 
reincarnations of 15 year old ESB SOA; they are entirely new orchestration 
tools, intelligent reverse proxies that have access to independent 
microservices. Less a manager and more a conductor, tools like Kong and 
Tyk can regulate microservice message traffic, inspect messages, handle 
service discovery, security, health checks, administration interfaces, 
comprehensive metrics, microservice level circuit breaker & bulkhead error 
handling - across system fault tolerance, reporting, analyze headers, and can 
merge messages from many microservices to transform a return response, 
and obfuscate the downstream microservices with upstream MAPI-PMG 
service URLs. 


Monitoring of the system, particularly all the downstream microservices, 
their datastore connections, the request calls, and responses, is fully 
configurable and handled by the MAPI-PMG. Notifications that need to be 
sent based upon the predetermined frequency configured by the organization 
are another task that the MAPI-PMG handles admirably. 


There is a balance between receiving enough data and too much data. 
MAPI-PMGs have the capability to provide an avalanche of data points 
from across a multitude of microservices, every connection, interface 
interaction, endpoint call, and many more top-level system details. Those 
who make it their business to analyze information always have trouble 
differentiating noise from meaningful information - the signal. 


The closer we get to the source of data generation, the higher the frequency 
of retrieval, and the denser the data, the more noise or random information. 
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That is why it is important to reduce the frequency of data retrieval so that 
more signal or relevant information can be isolated from less and less noise. 
Having the MAPI-PMG frequently tap into every single microservice and 
system interaction is not desirable. Balance between what is considered 
essential information coming from the in-production system and the not so 
essential data is the key to keeping noise down to a mere hum. 


Drowning in data is bad. The dilemma becomes one of focus. What should 
our attention be directed upon? Being immersed in noise, this over 
saturation of data promotes an overreaction on the part of those responsible 
for maintaining system health. Too many signals like too much noise is 
distracting, inhibits meaningful reflection, retrospection, innovation, and 
introspection by human minds buried in analysis churns. 


Worse still is acting upon the recommendations of staff subsumed in those 
analysis churns. Typically, these recommendations are overreactions to what 
is mostly noise in the aggregate. Real information that prevents calamities or 
proactively enhances the sustainability and coherent operation of a system 
should be acted upon. Continually ‘fine-tuning’ based upon excessively 
frequent analysis churns is over intervention to what is in all likelihood just 
noise. Better to procrastinate, not react to every single clump of seemingly 
important data. Give the system time to compensate, strengthen in an 
antifragile way. 


Dynamic behavior transitions, unanticipated aggregate system state changes 
are very possible in a distributed MAPI-PMG orchestrated Microservice 
Architecture. Basically, do not fall into the trap of overcompensating, over 
intervening, and especially, over reacting to what may just be a ‘louder’ 
higher frequency clump of noise that should not be unduly isolated, 
analyzed, or ‘corrected’. 


Just like the human body is complex in its totality. Similarly, a Microservice 
Architecture is complex in the aggregate as a singular entity comprised of 
many microservices, internal microservice implementation dependencies, 
datastores, and miscellaneous elements. Drilling downstream past the 
MAPI-PMG we find small and simple microservice components sending 
and receiving messages that may or may not be amalgamated or transformed 
into something more meaningful by the MAPI-PMG. All the various 
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interactions across what is a very fluid and dynamic set of contexts and their 
models within the entire system domain have the tendency to generate very 
diverse behaviors. 


Abstracting system connectivity, upstream externally exposed MAPI-PMG 
service connections to obfuscated downstream microservices, and 
microservice transformations up to the MAPI-PMG layer ensures that each 
microservice is left undisturbed. Left to remain its own unique self- 
contained entity each microservice does not need to have any dependencies 
or connections to or from other microservices. 


Complexity flows up from downstream microservices to the MAPI-PMG 
orchestration abstraction layer. All MAPI-PMG interactions across the 
system domain should be kept to a bare minimum to stop unwarranted 
complexity from creeping into what should be a simple and comprehensible 
Microservice Architecture. 


The theme that has been reiterated time and time again on many pages is: 
simplicity. Do nothing to increase the complexity of a system based upon a 
Microservice Architecture. This includes keeping the MAPI-PMG 
orchestration layer free of unwarranted downstream microservice 
entanglements. The MAPI-PMG abstraction layer must be free of gunk code 
that will over time congeal formally discrete microservices into an entangled 
complex incomprehensibility. 


Utilize the MAPI-PMG abstraction layer to transform and easily compose 
from the downstream microservice endpoints any system configuration or 
higher level application behaviors and states that are desired. Using a 
Microservice Architecture that is abstracted out by a MAPI-PMG exposes to 
the developer and architect all the downstream microservice building blocks 
needed to construct any application. The downstream endpoints are kept 
safely tucked away behind the MAPI-PMG. 


By intelligently transforming the downstream microservice calls the MAPI- 
PMG eliminates “chatty interfaces” that are the disdain of many a mobile 
developer not wanting to make many microservice calls to get the data 
needed. Whatever the call combination the MAPI-PMG can be configured 
by mapping to the required microservices necessary to retrieve the data 
needed by a single call to a MAPI-PMG service. MAPI-PMG externally 
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exposed web services will provide the data necessary by aggregating it from 
many microservice sources or mapping directly to a single downstream 
microservice in a predetermined way. 


Flexibility is the key to success in a Microservice Architecture. 


Data retrieval through transformation of downstream microservices and the 
orchestration of these microservices should therefore be left to a fully 
configurable MAPI-PMG abstraction layer. Never create lumps of mangled 
code spewing dependencies across microservices. Any changes necessary in 
a Microservice Architecture must be clean, elegant, and simple without 
adding superfluous extravagance. Using the MAPI-PMG abstraction layer to 
keep entanglements out of downstream microservices is a must to stay clear 
of unintentionally creating a Frankenstein distributed monolith just as 
incomprehensible as its non-distributed sibling. 


If another microservice delimited context is needed just code it up using 
whatever programming language makes sense, access the data from its own 
database schema, and expose the interface. Microservice Architecture is a 
very malleable easily configured lightweight componentized architecture, 
unlike the crystal palace Monolith that is a huge bunch of munged up code 
that is all interconnected across many functional domains. 
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Orchestration and Transformation 
Single-responsibiity of independent microservices is orl 
maintained through the orchestration of many 
microservices that can have the resulting responses 
transformed into a one meaningful response solving the 
N+1 queries problem, This avoids chatty interfaces 
shunned by mobile developers - the process of calling 
many microservices to get the data required, 


To handle the scaling requirements of a Microservice Architecture each 
microservice and all associated dependencies should be added to a Docker 
container. Some may believe that Virtual Containers (VCs) are over utilized 
in a Microservice Architecture. Holding every modularized appendage of a 
Microservice Architecture within hundreds or thousands of Docker 
containers all orchestrated by Kubernetes is the micro-conceptualization key 
to this design pattern. Once again, simplify down to the smallest 
componentized entities. 
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Antifragile Characteristics of Microservice 
Architecture 


Having many components or parts, a Microservice Architecture maximizes 
the antifragility of the entire structure. Microservice Architecture inherently 
enhances system noise due to the many microservice interactions. This 
increased noise reduces the fragility of a Microservice Architecture and 
optimizes its antifragility with environmental stressors that tug and pull at 
the system in many different ways allowing the system to get stronger. 


With continuous development, integration, and deployment, the proactive 
and reactive adaptation of a Microservice Architecture exhibits evolutionary 
architectural traits that keep it scaling without incidence and remaining 
relevant within whatever environment it is situated. This type of micro, 
small, and simple design pattern may be perturbed by many stressors but 
never an off-the-cliff event that is so typical of an inflexible, over- 
engineered, complex, and fragile monolith. 


Slight error perturbations in a fragile monolith can ripple across the entire 
framework causing catastrophic failure of the entire singularity that is the 
mono-system. Typically, there are no circuit breakers or bulkheads in a 
Monolith like in a Microservice Architecture. These design patterns when 
implemented appropriately preclude a total failure of the entire system. 


An indivisible blob of interdependent code a monolith will fail miserably 
when any part of the beast suffers an eruption of errors - the spillover cannot 
be contained - it will plunge into the abyss. Large crystal palace ‘perfect’ 
systems can be brought down by the least improbable stressor or isolated 
event. 


With many disconnected small parts a Microservice Architecture may have 
many more isolated failures in many microservices but these occurrences are 
like so much background noise. At the system level of operation they are 
typically insignificant and ultimately inhibited from destabilizing the whole 
system. Using the Circuit Breaker and Bulkhead design patterns 
implemented across an application, total system-wide failure is 
inconceivable. Inherent instability at the micro level makes a Microservice 
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Architecture stable at the macro level. Building up its antifragility from its 
imperfect interactions in a stressor filled world continually strengthens the 
system. 


Every part of a Microservice Architecture is loosely coupled, not dependent 
upon any other component, module, or segment. Microservice Architecture 
is like our organic cellular componentization all alike from a molecular 
standpoint but each a unique unit of functionality. 


Cells can die from internal or external stressors typically without killing us. 
Obviously, no system that is natural or human designed is immune from 
massive widespread componentized destruction. If too many cells die, 
especially those of primary organs the stress to the organism will be so 
extreme that it will not be able to withstand the trauma and the whole 
biological entity may cease to exist. Similarly, if many microservices fail the 
entire system may fail, but as already discussed this is not a probable 
outcome when the proper safety measures such as the Circuit Breaker and 
Bulkhead design patterns have been implemented. 


The behavior of such a system that is simple at a granular level but complex 
like our entire human body at a macro level can have emergent behaviors. 
Thinking back to my early work starting in 2006 on military System-of- 
Systems (SoS) like the Future Combat System and Sustainment Data System 
what strikes me is just how similar at a conceptual level these systems were 
to a Microservice Architecture. System-of-Systems were composed of 
unique and autonomous but not small systems, all orchestrated but not 
controlled to produce goal oriented behaviors. 


That is the key concept: goal oriented behaviors, the set of emergent 
behaviors that result from the interplay of each system in a SoS or distinct 
microservices in a Microservice Architecture. To maintain the antifragile 
nature of these composite buildups so similar to how natural systems are 
comprised we must not exert control over them in an attempt to build in 
determinism that is beyond our abilities within the interplay of chaotic 
internal and external environmental contexts. 


Even though we cannot control the emergent behaviors that result in a 

Microservice Architecture it is still prudent to at least try to map out or 

understand the set of emergent behaviors that results from the diversity of 
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change inherent to these types of systems. Are the emergent behaviors 
consistent with the objectives and goals outlined for the system? What is it 
that is trying to be accomplished with the particular system - generation of 
revenue, transference of knowledge, marketing of business presence, or 
some other objective? Do the emergent behaviors align to the objectives for 
the system? 


ass Microservices 
Diversity of Change es, 
Microservice Coordination 

Sequence of requests 

User diversity 


Changes made to microservices Emergent 


Behaviors 


Changes made to MAPI-PMG 

Number of microservices 

Frequency of microservice requests 
Nas 


My experience and outcomes with designing and developing System-of- 
Systems back in the early 2000’s - though less-granular and having full- 
blown system components, these System-of-Systems also spawned emergent 
behaviors. 
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Desired Complex System Behaviors 


Interactions of 
Autonomous and 
Simple 
Microservices 


It is interesting that all these years later my early cave dwellers knowledge 
can be utilized in a more micro less macro technical setting. Microservice 
Architecture is nothing more than taking SoS and simplifying all the 
components (using microservices instead of systems) to their most simplistic 


state of single-purpose basic entities. 


Some of my former compadres working on System-of-Systems must have 
used their knowledge of this type of system that was a larger componentized 
version of a Microservice Architecture to become rich and famous. Isn’t it 
odd how life sometimes plays out for those of us less fortunate at connecting 
with the right movers-and-shakers? My knowledge being one of the singular 
crucial elements essential to the creation of SoS technology architectures 
and development is now finally able to help enlighten the tech community 
on the freakily similar Microservice Architecture. But this will happen 
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without the fame and riches to accompany this exposition. 


Getting back to the drama-less technical dissertation it is evident that single- 
purpose simple microservices acting in concert through some form of 
MAPI-PMG coordination promotes emergent behaviors that are antifragile 
in response to environmental stressors that impact the system. 


Very important to the maintenance of the evolutionary and antifragile 
characteristics of a microservice system is the reduction or elimination of all 
policies, governance, audits, and rules that attempt to exert control over the 
system. Let the damn thing be free in its expression of how it reacts to 
environmental stimuli/stressors or else spend all your time trying to plug the 
many holes springing leaks in the dike. 


It is foolhardy to assume that any level of meaningful control over the 
imperfect creations of an imperfect humanity can be realized. There have 
been numerous examples throughout history especially within the 
technology sector where the ‘impossible’ occurred even though the 
probability of such an occurrence made such an outcome ‘impossible’. 
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Cc ntrol Edifices 


Policies 
Governance 
Audits 


Illusory attempts to lockdown everything through standardization and what 
can be termed control elements will only destroy the single most important 
part of a Microservice Architecture - its antifragility or the ability of the 
system to positively adapt and grow stronger and better from emergent 
behaviors and swift incremental changes made by the microservice teams. 
Ill-fated attempts at control will only destroy the adaptability of a 
Microservice Architecture system. 


Introducing excessive control edifices is humanity's attempt to feel 
empowered against nature’s unrelenting dynamism. Our feeble thrusts at 
directing change so that we do not feel powerless in an avalanche of events 
we are helpless at steering towards desired outcomes is just our desire to be 
relevant in a universe that needs no single planet or its inhabitants. 
Regulating and controlling their fellow human beings makes a few 
controller types feel powerful in the face of their own insignificance. This 
dictatorial control deviance leaking into a more advanced and 
environmentally tuned Microservice Architecture destroys its ability to 
continually strengthen through adaptation. 
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Over regulation, our human need to control for the sake of perceived 
stability only enforces our complacency within our neatly ordered control 
spaces. We lazily drift off into set patterns of behavior, daily routines, and 
stagnation when we temporarily inhibit the stressors that are necessary to 
keep ourselves and our systems antifragile. Over time in our pat and tidy 
little worlds without regular impacts from stressors the ‘pressure cooker’ 
holding back reality builds up, accumulating so many stressors that the top 
blows off. 


Systems need to experience turmoil without ineffectual artificial shielding. 
Our systems should be exposed to the world without protection from every 
negative eventuality. Similar to how we release our offspring into the 
tumultuous environment after so many years of learning and preparing them 
to be antifragile, to get stronger from the adversity that life throws at them. 
Similarly our systems should be equally ready to ‘stand on their own two 
feet’. Overcompensating with controls, regulations, shields, and any other 
contrivances, ultimately has the effect of weakening, not strengthening 
systems or individuals that are unable to withstand the stressors of the real 
world. 


Sheltering our children from challenges, to let them live in what we perceive 
to be safe and aseptic environments does not prepare them for the hard 
knocks - the stressors. Likewise the artificial entities that we create must 
fully experience the dynamic, untidy, and mostly destabilized events and 
stressors with minimal shielding from a physics driven, unsympathetic, and 
impersonal universe. 


Expose all systems and entities to the real world providing only limited 
protections. 


Firewalls that act like basic laws in a human society should never over 
compensate for every eventuality but only be our ineffectual best effort 
responses to the antifragile interplay of entities and physical laws within our 
tumultuous natural surroundings. Let our systems learn like we ourselves 
learn from our experiences, daily getting stronger, more antifragile - better 
able to adapt with our incremental assistance until the day when they are 
advanced artificial sentients able to navigate the untidy trails through the 
wild forest of nature. 
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Harden the primary systems, not the shielding. Build up the antifragility of 
our systems. Do not keep them sheltered in ‘safe houses’, the perceptually 
perfect environs behind a DMZ. Unable to withstand the shocks that the real 
world will hit them with, the many bad actors relishing a chance to hack the 
living daylights out of our pristine, ‘inexperienced’, and fragile systems. 
This safeguarding of what we value only insures eventual disaster. Imperfect 
human beings like ourselves do not create perfect artificial entities - never 
had and never will. 


Excessive control and 
s] standardization tries to eliminate 
4 undesirable system outcomes and 
behaviors but only perpetuates 
them by exposing a now 
unadaptable and fragile NOT 
adaptable and antifragile system 
to the environment 


Attempt 
ing to remove uncertainty from a system by leaning too heavily on 
standardization, control, policies, and other forms of control in an uncertain, 
dynamic, and chaotic world only has the effect of reducing innovation and 
promoting the very negative characteristics and outcomes that are trying to 
be avoided. That is not to say that standardization or control is bad, only that 
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micromanaging, the reliance upon excessive hierarchical control, eventually 
over time inhibits and destroys the antifragility of freely creative teams and 
their attempts to positively strengthen dynamic Microservice Architecture 
based systems. 


Autonomous systems and teams within a collaborative and cooperative 
organizational culture that does not impede progress destroy creativity, and 
change a Microservice Architecture from antifragile to fragile is only 
possible within a flattened influence structure founded upon respect and 
inclusion. It is a fallacy that control can be positively exerted over every 
organizational interaction within the environment - only the destruction of 
naturally occurring antifragile entities and systems will be the unintended 
consequences of such ignorance. 


Emergent behaviors that result from the free interplay of our systems with 
the stressors of their environments should not be the enemy but cherished 
externalities. Without emergent behaviors that are understood or anticipated 
a system based upon Microservice Architecture is effort needlessly 
expended that could have been better applied building a highly coupled, 
constrained, and illusory deterministic system - a monolith. Keeping 
antifragility intact and undisturbed is the art of infusing a typically 
dictatorial culture like capitalism with more than a semblance of freedom 
and effortless organizational cooperation. This is not an easy task because it 
is counter to everything taught in management schools. 


But the world is not a predictable place, natural systems are antifragile, 
strengthening when hit with environmental stressors that are wholly 
unpredictable regardless of what the probability experts propagandize. By 
believing for a minute we can control our world, any part of it, whether it is 
the systems we create with imperfect knowledge or the events we view with 
a limited field of vision and understanding we are only entertaining a fools 
dream and setting ourselves up for many failures, some even disastrous. 


Complexity built up from simplicity, antifragility, and iterative destruction 
and creation are the hallmarks of our natural environment. Why not just 
embrace these characteristics and imbue our systems with them instead of 
putting our finger in the proverbial dike only to realize that we are unable to 
stop all the leaks because we are not omnipotent beings but just humans 
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trying to do our best in a universe that is constantly throwing curve balls at 
us. 


Instead, we should endeavor to holistically understand the world’s 
antifragile systems, the standard simplicity in the weeds that builds to 
adaptable, manageable, and strengthening complexity in the forest. Create 
systems that emulate this elegance without destroying it with imperfectly 
perceived perfection. Nature is inherently untidy, messy, seemingly 
disordered, and random, but that is only because it is antifragile - adaptively 
strengthening like the mutating viruses and bacteria evolving to resist our 
best attempts to kill them with antibiotics. 


Our systems, the architectural foundations of the applications that we build 
must also cleave to the basic constructs found in our natural world. We must 
not destroy the antifragility of a Microservice Architecture by creating a 
‘perfect lawn’ when we could just let it grow naturally and strengthen 
without adding destructive ‘fertilizers’ and ‘weed killers’. 


In the same vein, do not suffocate a Microservice Architecture by trying to 
create what we humans deem to be perfection for it is only the realization of 
destroying antifragility - the continuance of natural adaptation and 
strengthening that will be the outcome of our quest for perfection. 


Efforts should instead be directed at inducing regular unplanned failures 
across systems similar to how Netflix uses its “Simian Army” to challenge 
its systems - enabling them to grow stronger from emergent behaviors and 
lightning fast release improvements. Microservice Architecture with its 
many discrete microservices that are all self-contained entities that together 
create the orchestrated emergent behaviors desired of a particular system 
make excellent targets of failure bots that when properly deployed can make 
the entire system stronger with each stressor they introduce. 


Failure bots should not only be deployed across the deployment pipeline of 
an automated DevOps CD, CI, CProd, and deployment environment but 
should also throw stressors at the production system’s many microservices. 
Constantly challenging the individual entities that are the microservices 
makes the entire system more antifragile. 
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Failure Bots 


Failure Bots need to have access 
to downstream microservices to 
promote stressors that have the 
effect of strengthening - 
enhancing the Antifragile nature 
of the entire system 


NN 
API Platform 


API Gateway 


Developer Portal API Manager Admin Portal 


Certain downstream 
— microservices are purposely 
made to fail stressing the entire 


system so it can become more 
antifragile 


Many more pages could be written on this new way of viewing our 
interactions with our world - this antifragile conceptualization of how 
entities engage and are engaged within nature’s untidy universe. Not doing 
justice to the concepts of antifragility because Nassim Nicholas Taleb, the 
intellect that is helping us mere mortals understand the interplay of entities 
within our real world makes this author’s musings like those of a child’s 
first words. You must therefore read his book “Antifragile” to fully 
appreciate this new view of the chaotic spaces we and our systems inhabit. 
A reference to Nassim Nicholas Taleb’s “Antifragile” can be found in my 


suggested readings list at the back of this book. 
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Service Mesh 


Independence of each microservice in a Microservice Architecture is the 
primary objective needed to maintain flexible continuous change and the 
ability of this design pattern to easily scale. Objectives are not hard fast rigid 
constraints, in a world that continually changes and adapts too many 
stressors and triggers we cannot be absolutely certain that when building a 
real world system that there will never be the case when two microservices 
will need to pass messages. 


What is typically called a Service Mesh with its associated Sidecars that are 
microservice close proximity proxies connecting a microservice into a 
communications mesh can adequately deal with the need of some 
downstream microservices to pass each other messages. Once a 
microservice is connected to a Service Mesh through its close proximity 
Sidecar, messages can then be exchanged between it and other 
microservices in a coherent and regulated way by the Service Mesh. 


Try never to utilize a Service Mesh. Only if absolutely necessary should this 
nastiness be injected into an elegant Microservice Architecture, and then 
only temporarily. This design pattern corrupts the entire foundational 
underpinnings of a Microservice Architecture. Make it a quick fix when 
there is no time to appropriately address an inadequacy in your system 
design. 


Unfortunately, it has been my experience that temporary expediency is the 
short path to technical debt that is harder to deal with the longer it is allowed 
to fester within a system. It is much better to take the time upfront to keep 
your system clean and elegant than to take the easy way out by 
accumulating debt. Debt is bad in all its evil forms. Debt just keeps 
accumulating once you start relying upon it. But in the interests of 
completeness this deviant design pattern is presented in an architectural 
diagram. 
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Enterprise Service Bus (ESB) Is Not a MAPI- 
PMG 


There seems to be quite a bit of confusion surrounding an MAPI-PMG. 
Some believe that an Enterprise Service Bus (ESB) like MuleSoft, 
especially given how this framework has been recently marketed, has now 
been miraculously transformed into a modern MAPI-PMG microservice 
orchestration management/gateway. All ESBs, especially MuleSoft are 
tightly bound distributed monoliths that glue all the components, dumb 
services, and disparate subsystems of a tightly coupled system to its central 
control architecture. Just stay away from these beasts like a werewolf when 
there is a full moon. 


MuleSoft is an Enterprise Service Bus (ESB) 


15+ year old SOA design pattern 
No benefits to older 3-Tier architectures 
* Business logic centralization 


* Dumb services 
». Very-high development costs 


istributed monolith 
Tightly coupled 
Context and code smeared across framework 
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How is a Microservice Architecture Different 
from a Monolith 
Centralization, absolute control, and the always increasing size of the 


Monolith are radically different from the decentralized and totally decoupled 
Microservice Architecture. 


~ Monolith 


Centralized 
Dependent 
Flexible inflexible 
Antifragile Fragile 
Irreplaceable 
Large 
Complex 
Breaks at Scale 


Low Change Velocity 


Spending most of my early career trying to create crystal palaces, pure 
monoliths that most of us dinosaur ranchers believed could anticipate every 
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eventuality or stressor that the real world would throw at them, every state, 
either resting, transition, and that perfect never achieved state, let me say 
unequivocally that this is a fool’s waste of time. We humans, all our 
imperfections, in an imperfect, but very stressor adapted untidy world are 
wholly incapable of creating anything perfect and that is especially true 
when it comes to maintaining or managing any system state effectively. 


If our natural environment operates on malformed conceptualizations, a 
constant turmoil, throwing stressors out like small doses of poison, that 
somehow equates to stability in the aggregate when viewed holistically, up 
high, why do we mere mortals believe we can craft the perfect anything? So 
take it from someone who tried to envision control systems, artificial 
intellects that could conceivably anticipate their state changes, make 
corrections based upon state transitions, and move to this ‘perfect’ state - 
this is bunk. It is nothing but stupidity and arrogance to assume we can 
anticipate every stressor, its impact on the current state of a system, what 
that transitional system state will be, and then know beyond the shadow of a 
doubt what the ‘resting’ or desired state of a system or component will 
resolve to all under our ‘supreme’ direction! 


That is why we must move on from trying to construct the perfect system 
monolith all neatly wired into beautifully flawed application servers that 
‘handle’ scaling and every eventuality, ‘anticipating’ every stressor that can 
impact the obese system, and presuming these beasts have preeminent 
clairvoyance. Just the process of months long delayed dumps of mammoth 
tightly wound hunks of code like WAR files all with their pristine 
dependencies spelled out nicely into an operations lockstep build process is 
further proof of the temporary insanity that infected the infant technology 
industry. 


Microservice Architecture is an awakening from the belief that we an 
imperfect creation can or want to make anything seemingly perfect so that it 
cannot withstand the naturally imperfect stressors thrown its way. Instead 
our industry is now striving to comprehend how to build systems like a 
Microservice Architecture that emulate the disordered mess that is the 
beauty of the sustainable natural processes all real world entities are 
subsumed within. 
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Many unique elements comprise the ecosystems of this diverse planet. No 
single entity is so important or preeminently perfect. There are many pieces, 
components so numerous that we are still finding subatomic particles even 
though our minds needing a sense of order places limits on infinity - there 
just must be a termination point. Really, why is that the case if the universe 
is unfathomable? When our universe merges with other universes some 
alternate in their composition with antimatter and flip sided laws of physics 
do we presume there is an end, or that we really know anything fiddling 
with our stones in a cave. Maybe, there is infinitum with no progenitors - 
just endlessness merging with endlessness. 


Inspiring this Microservice Architecture paradigm shift that emphasizes 
many small, adaptable, self-contained, and unique microservices is just such 
a realization that our world is densely complex in its diverse natural 
untidiness and continuity. Therefore, if our systems are to be a true unbiased 
reflection of this natural reality they also need to be comprised of many 
unique components able to come and go, and adapt, all with extreme 
iterative frequency. Our systems need to also be antifragile - have the ability 
to get stronger from the stressors that are thrown at them daily. 


Large obese things are bad. Small agile many faceted pieces, components, 
what we have termed in our technology industry microservices are good. We 
can build them very fast; get rid of them if needed, just like nature 
terminates inefficient or genetically flawed entities swiftly. Building up 
from the smallest or even smaller, until the macro entity is functional, able 
to survive, and get stronger. Conceptually that is what Microservice 
Architecture is attempting to accomplish - with our feeble thrusts at 
recreating a natural ecosystem synthetically for our own benefit. 


Design patterns that provide many options, like Microservice Architecture 
are more flexible and able to adapt, becoming a stronger more antifragile 
system. Options are the ingredients that determine how antifragile a system 
is whether a natural or human-made technological creation. Therefore the 
more options the system has to avail itself of the more antifragile it is - the 
more resilient and stronger it can become. In order to evolve a system over 
time, moving it towards a simpler, maintenance lean, adaptable, and 
antifragile higher level entity, the exploitation of optionality must progress 
without impedance. Typically, this requires an organization comprised of 
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courageous and imaginative individuals having the ability to communicate 
unrestricted across all business channels and pathways. 


Just like this book is concise without any fluff, or filling, just the needed 
information, our thought processes should be similar - free from needless 
inhibitions, controls, preconditions, extra junk, restrictions, and all the other 
large rocks that block our intuitive cognition and betterment. Never believe 
for a second that this author or anyone else has all the answers. My 
experience and knowledge can only guide your steps into this small, 
decomposable, and eons old ecosystem that we humans are just now trying 
to emulate in Microservice Architecture. 
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Using Technology Archimetrics to Contrast 
Microservice Architecture from a Monolith 


The term that I use for my new analysis of system and technical architecture 
dynamics is Technical Archimetrics. Prefacing Archimetrics with the word 
technical is essential because this term is also used in the brick and mortar 
architectural profession. Not satisfied with simple descriptions of various 
technical architectural states my intention is to quantify and qualify these 
changes with intuitive linear diagrams. 


Let us first look at what happens when the decision is made to move from a 
Monolith or ESB SOA Architecture to a Microservice Architecture. 


Microservice Architecture having many single purpose, decentralized, 
autonomous, replaceable, small, and simple microservices enables a higher 
change velocity as a function of time than a multipurpose, centralized, 
dependent, not easily refactored or replaced, large, and complex monolith. 


Microservice Architecture 


Monolith 


A Velocity 


Time 


As change velocity increases, system production safety decreases and the 
probability of production errors or malfunctions also increase. Microservice 
Architecture only operates at a higher level of system production safety as a 
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function of change velocity when DevOps, operations automation, CD, CI, 
CDeploy, Agile, and all the requisite changes have been made organization 
wide to make a Microservice Architecture a success. 


Safety 


’ A Velocity 


The 
fewer the components that a system has and the dependence of each 
component upon other components or what can be called a Controller 
Design Pattern where each component is subservient to a core or central 
logic layer the more monolith the system. Gradation in monolith 
characteristics - a continuum from non-monolith to absolute monolith is a 
more realistic measure of system centralization, inter-component 
dependency, and the flexibility or adaptability of a system to change - its 
resiliency and antifragility. 


The monolithic characteristics of a system are a function of the number of 
independent components that a system processes and their overall autonomy 
and independence. Pure monolith systems are rare, just like a pure 
Microservice Architecture. Nature does not create such well-defined 
absolutes and neither do imperfect human beings whose creations also 
interact in a messy imperfect but well balanced antifragile world. 
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Monolith 


Independent Components 


There are numerous benefits when moving from a monolith to a 
Microservice Architecture that mostly originates from the independence 
afforded the multidisciplinary teams and each microservice that is its own 
self-contained entity. When looking at component independence in relation 
to the production availability of an application or system it should be readily 
apparent that as a system’s components become more independent, the 
system is more production available. There are many more points of failure 
that cannot singularly bring down an entire system. The system becomes 
more efficient, adaptable, resilient, and antifragile, building up strength from 
constantly be exposed to environmental stressors. 
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Microservice Architecture 


Availability 


0 Component Independence 


Innovation is also promoted because each microservice or its 
implementation can be easily replaced. Each microservice is a separate and 
unique fully self-contained entity with its own dependencies, internal 
implementation obfuscated by its interface, datastore linkage or messaging, 
build, deployment, and production ready capabilities. 


Contrast this with a monolith that is a WAR or other obese blob of 
intertwined code. With cross dependencies and a multitude of highly 
coupled components all tightly woven in a complex patchwork even a 
simple change to this beast necessitates the build and deployment of the 
entire codebase. A new WAR or other container type artifact must be 
generated. 
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Innovation 


0 Component Independence 


Easily Replaced 


0 Component Independence 
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In order to maintain the component independence of a Microservice 
Architecture it is absolutely important that individual microservice linkages 
to other entities be kept to a minimum, or better still never pollute this 
elegant design pattern. Utilizing publish and subscribe tools like Kafka to 
exchange messages between microservices or a datastore of a microservice, 
or using a Service Mesh Sidecar proxy will reduce the microservice 
component independence and efficiency of a Microservice Architecture 
based system. 


Flexibility, the ability to “turn-on-a-dime”, making changes that do not 
impact a large unfathomable interconnected codebase like that found in a 
Monolith, ESB SOA, and a service layer that is an incomprehensible 
distributed mess of dependencies can only be achieved by adhering to the 
precepts central to a Microservice Architecture. 


Each single-purpose microservice must be independent, unencumbered, and 
a distinct entity not tied to a riddle of interlocked dependencies, messages, 
and cross-purpose connections. Always remember that component 
independence is a byproduct of simple design and comprehensible 
outcomes. Anything that seems to be too complex is probably very complex 
and needs to be decomposed - simplified. 


The foundational concepts of a Microservice Architecture must be 
understood and implemented from an organizational, software engineering, 
and operations standpoint for this paradigm shift to be successful. 
Culturally, this can be a very difficult pill to swallow especially for those 
acclimated from childhood that big is good, complexity can be managed, 
small is inherently inferior, and control is more efficient that cooperative 
orchestration. 
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Unique and independent microservices can also easily utilize any 
programming language, tools, and internal dependencies that are best suited 
for the task. This is possible because each microservice is an independent 


component that is self-contained and separately deployed - a unique piece of 
a larger entity. 


Polyglotism 


0 Component Independence 


Compon 
ent independence infers that each component is less dependent upon its 


internal and external environment. When something is less dependent upon 
other entities or the environment to continue its existence it is typically more 
resilient. Microservice Architecture is able to withstand environmental 
stressors better than a monolith but it also has a characteristic significantly 
more important than simple resilience to withstand a turbulent world - this 
architecture is antifragile - strengthens from the trials of adversity. 
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Microservice Architecture 


Resilience 


Monolith 


0 Dependence 


A highly adaptable Microservice Architecture with inherently immutable 
microservices that are easily replaced is by its very nature antifragile - a 
self-strengthening entity. Incremental improvements, either proactive, or 
reactive from emergent behaviors, an outcome of mitigating the impact of 
stressors, and the consequent antifragile strength that is a byproduct of 
changes made to a system based upon a Microservice Architecture is a 
function of the number of stressors that impact the system or application. 
More stress is better than less, if adaptable strengthening is the desired 
outcome. 


Therefore, the level of antifragility of a Microservice Architecture is a 
function of stressor impacts. Less adaptable and antifragile systems tend to 
be more like monoliths with fewer components. Highly componentized 
applications with few to no internal connections between components tend 
towards the characteristics of a Microservice Architecture on a continuum 
from pure monolith to pure Microservice Architecture. The fragile systems 
tend to be pure monolith with the more stressor impacted systems tending to 
be more antifragile - all things being equal. 
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Antifragility is therefore not exclusively a characteristic of a Microservice 
Architecture but can also be a positive trait of a monolith that is more 
componentized and having less interconnected internal process flows being 
impacted more regularly by stressors. Any system that is designed according 
to the Microservice Architecture philosophy and adheres to the full spectrum 
of multifaceted requirements both technological and organizational is also 
antifragile. 


Antifragility 


0 Stressors 


Any system’s strength regardless of whether a monolith or Microservice 
Architecture will be a direct result of the number of stressors that impact its 
many control surfaces as a function of time. Therefore, it is imperative that 
our systems be exposed to the larger environment and not sheltered from 
negative consequences that we are ineffectual at stopping. 
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Decomposing a Monolith 


The entire conceptual origin of a Microservice Architecture design pattern 
came from the need to logically breakup unwieldy, unmanageable, and 
inflexible, process constrained, and tightly coupled monoliths. These beasts 
were infused into overly complex frameworks like Java EE and .NET that 
also had application servers requiring constant maintenance and technical 
handholding. 


With the need to decompose the monolith in an organized fashion so that the 
functionality of the behemoths would not be adversely impacted came the 
need for a design pattern that could be applied in a least cost, effortless, and 
timely way. Replacing key portions of the monolith with microservices that 
encapsulate DDD single purpose context bounded functionality is termed 
the Strangler Design Pattern. 
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Strangler Design Pattern 


The Monolit is slowly strangled into eventual 
nonexistence by offloading relevant bounded 

contexts into single purpose microservices not 
coupled to other microservices, 
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Strangler Design Pattern 


Phase ll 
Strip-out internal Monolith microservice request calls moving these to the new web client 
application that will gradually replace all Monolith functionality until the Monolith is strangled 
out of existence. 
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Deploying a Microservice Architecture on the 
Cloud 


Along with the unreality that ESB SOA is somehow a Microservice 
Architecture another equally disturbing misconception is that a Microservice 
Architecture is integrally tied to the Cloud. Cloud technologies like AWS, 
Azure, and a host of others are distinct and separate from a Microservice 
Architecture. Whether an organization decides to utilize the services of a 
Cloud for PaaS, IaaS, or SaaS is a mutually exclusive decision distinct from 
whether to use or not use a Microservice Architecture. 


This does not mean that using the Cloud instead of maintaining your 
technical infrastructure in house is not advantageous from the standpoint of 
reducing costs associated with operations especially where a Microservice 
Architecture is concerned. Not having to micromanage the VMs associated 
with a Microservice Architecture like when utilizing Amazon’s Elastic 
Compute Cloud (ECS) is a huge timesaver and relief for most companies 
using a very scalable and adaptive Microservice Architecture. 
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AWS EC2 Preprovisioned VMs Using Kubernetes Container 
Management Platform with Docker Containers 


Amazon ECS (Elastic Compute Cloud 
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AWS EC2 Preprovisioned VMs Using Kubemetes Container 
Management Platform with Docker Containers 


Amazon ECS (Elastic Compute Cloud) 


VM 
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Microservice Architecture Security 


Obfuscating the backend microservices in front of a reverse proxy like a 
Microservice API Platform Management/Gateway (MAPI-PMG) similar to 
Kong and Tyk goes a long way in securing microservices that prior to the 
advent of a MAPI-PMG were externally exposed on the web. The Open 
Banking legislation in Europe and the UK mandates that all banks provide 
information that can be used by customers and Fintechs (operating as 3rd 
party aggregators for customers) to enhance the online banking experience. 


Security was addressed early on; the UK Open Banking rules recommend 
the use of the authentication OpenID Connect and the OAuth2 authorization 
frameworks. Pioneers like Kong and Tyk in the emerging MAPI-PMG 
technical space have plugins and modules necessary to support this 
advanced form of authentication and authorization. 


OpenID Connect 


OAuth2 


Kong also allows the use of a JWT Profile where a JWT assertion can obtain 
an OAuth? access token in Single Sign-On SSO. Advanced MAPI-PMGs 
can employ fine-grained key authentication plugins or modules that protect 
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the downstream microservices API from unauthorized use allowing only 
requests with the correct API Key to proxy through the MAPI-PMG - all 
others are rejected. 


Never assume that just because microservices are downstream behind a 
firewall and inside the DMZ that they are safe from external infiltration if 
they are not behind the MAPI-PMG security layer. All microservices must 
be secured by the MAPI-PMG - there can be no exceptions. With each 
microservice having its own micro-web server and all its required 
dependencies internalized within a Docker container it is absolutely 
essential that each and every microservice is secured by the MAPI-PMG. 
There can be no loose ends where security is concerned. Ask the many firms 
that have lost their customers private data or suffered any of the many 
reported security breaches how legally expensive and irreparably damaging 
these type of incidents are to their reputations and business results. 
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